fix: Keep a failing background watcher from breaking a successful actor call - #1027

Fix

actor.call() with the default logger='default' could raise on a run that had already succeeded. A status poll that failed after retries left the exception on the watcher task; stop() then cancelled an already-finished task and awaited it, re-raising past except asyncio.CancelledError. The sync twin leaked the same failure out of its thread.

Fixes, all on that path:

• Both watcher loops now use the handler StreamedLog._stream_log already had — warn on is_timeout_error, logger.exception otherwise — so a failed poll is reported instead of surfacing as a failure of the run.
• The sync watcher's thread is a daemon, so a watcher whose loop never terminates (missing run) cannot hold up interpreter shutdown.
• StreamedLog.stop() closes the stream response and bounds its join with _stop_timeout_s (5s), instead of joining unbounded on a stream that may not speak for hours.

Closing the response alone is not enough: on impit 0.13.2 Response.close() returns immediately and sets is_closed=True, but a reader blocked in iter_bytes() stays blocked, and closing the Client does not release it either. The close is kept because it is correct for a custom HTTP client; the bounded join is what makes stop() return.

5 new unit tests plus an integration test that fails a real run's background status polls, each red before the fix.

Why stop() is bounded this way

The bound is the third pass over the same problem, so for context:

• fix: prevent StreamedLog stop() from hanging on a silent stream #825 bounded stop() by requesting the log stream with a 30s read timeout.
• fix: prevent Actor log-streaming thread from crashing on stream timeout #944 removed that: impit applies timeout to the whole request, streamed body included, so a run that logged for longer than the bound was cut off mid-stream with impit.TimeoutException — the user report impit.TimeoutException in _streamed_log.py after successful actor completion #945. The stream has been requested with no_timeout since, and fix: prevent Actor log-streaming thread from crashing on stream timeout #944 recorded the resulting unbounded stop() as a known limitation, on the grounds that actor.call() is unaffected because run finish sends EOF.
• This PR bounds stop() without touching the stream request: a 5s cap on the join, plus a close on the response. _stream_timeout stays no_timeout — still asserted by test_streamed_log_sync_requests_stream_with_no_timeout — so impit.TimeoutException in _streamed_log.py after successful actor completion #945 cannot regress. What is fixed is the case fix: prevent Actor log-streaming thread from crashing on stream timeout #944 left open: a manual stop() on a stream that has gone quiet.

Trade-off: a thread that outlives the 5s cap keeps running as a daemon, so stop() can return before the tail is flushed. It does not happen on the actor.call() path, where the run's EOF ends the thread first — measured at 0.000s over repeated apify/hello-world runs.

✍️ Drafted by Claude Code